@SergiiDmytruk please rebase it, for some reason GitHub shows lines that are already changed in homer_2nd_cpu

By the way, "OCC" partition is still read twice (costing us an extra 400ms) only because I'm not sure what would be a good new place for "HCODE". Looks like can use common OCC area, any better place for it (maybe just use malloc())?

malloc() would be good, but it may require changing linker options, it only has 1MB of heap by default. 400ms may be worth it.

What about WOF, is it also loaded twice?

What about WOF, is it also loaded twice?

We don't read it all, only readat header, mmap list of entries and then mmap entry that we need.

Tried it in d653b55, but something is wrong with FIT:

CBFS: Found 'fallback/payload' @0x1f8c0 size 0x17575d in mcache @0xffefeb7c
FIT: Examine payload fallback/payload
FIT: Loading FIT from 0xf8380000
FIT: Image fdt-1 has 9351 bytes.
FIT: Image kernel has 1518576 bytes.
FIT: Compat preference (lowest to highest priority) : raptor-cs,talos-ii
FIT: config conf-1 (default), kernel kernel, fdt fdt-1, compat ibm,powernv ibm,p9-openbmc rcs,talos
FIT: No match, choosing default

Tried it in d653b55, but something is wrong with FIT

This is expected output from FIT so far, last line is truncated. Next printed line would be FIT: Updating devicetree memory entries, but before that it unpacks FDT to DT which also allocates memory.

I don't see any issue with linked commit so it will require deeper debugging, but for now this isn't a priority.

If I drop free() in 45bb540, it works. If I keep free(), but memset zeros, it works. If I keep free() and memset non-zeros, it doesn't. Some FIT/DT code uses uninitialized memory. @krystian-hebel, worth tracking down this memory issue? Maybe can find a commit that fixes it upstream, otherwise the bug is still there.

Also, the gain from reading OCC once is more than was expected: 558ms.

dt_find_node() didn't zero-initialize nodes it created, the bug is present upstream as well. It's just hard to notice when there are pretty much no free() calls, all memory is zeroed by default and special conditions must be met for a block to be reused.

After that fix reading OCC once works as expected.

Measured time it takes wof_init() to execute, just in case it's a lot: ~53ms for each chip. The delay comes from rdev_mmap() in wof_extract(), WOF entries might match for us, but not in general, so caching is probably unjustified (especially when compared to PNOR caching of MVPDs, which should save many seconds).